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(54) Stream data transfer control method and system 



(57) The present invention relates to a data transfer 
method and a system in a computer network to which 
are connected a number of computers, more specifically 
to a data transfer method of stream data continuous in 
time series and a system for it. The present invention 
makes a request for change of rate from the client 470 
in correspondence to the state of vacancy of said receiv- 
ing buffer 41 2, and changes the send rate on the server 
400 based on that request for change of rate. This pre- 
vents any overflow of stream data from the receiving 
buffer 412. Furthermore, based on the re-transfer re- 
quest issued from the client 470 in correspondence to 
the loss of stream data received by said packet receiving 
means 410, the storing means on the server 400 sends 
out data corresponding to the lost data concerned. This 
makes it possible to compensate for the loss in case of 
occurrence of any data loss. 
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Description 

FIELD OF THE INVENTION 

• 

The present invention relates to a data transfer 
method and a system in a computer network to which 
are connected a number of computers, more specifically 
to a data transfer method of stream data continuous in 
time series and a system for it. 

BACKGROUND OF THE INVENTION 

With improvement of computer capability and gen- 
eralization of connection to network of computers in re- 
cent years, there is a growing request for real time trans- 
fer of stream data through computer network. Stream 
data here means data continuous in time series such as 
image, sound, etc. This stream data is naturally incor- 
porated in packets and transferred through a network. 
Here this data is called stream data regardless whether 
the data is handled in units of prescribed number of 
groups of data or handled in disregard of such units of 
group. 

Fig. 14 shows an example of conventional stream 
data transfer system. This system is composed of a 
server 500 on the side providing data and a client 508 
on the side receiving the supply of data, and the network 
507 intervenes between the two. A conventional system 
will be further explained hereafter based on Fig. 14 to- 
gether with its procedure. 

The server 500 is constructed as described below. 
Namely, as explained hereafter, when a request for start 
of transfer of stream data is given from the client 508 to 
the sever, this request is delivered to the start request 
processing means 516 through the packet receiving 
means 501, and this start request processing means 
516 starts the rate controlling means 505. This rate con- 
trolling means 505 reads out stream data from the stor- 
ing device 503 such as hard disc, etc., and stores it in 
the transmission buffer 504 temporarily. 

A prescribed send rate is set in advance in said rate 
controlling means 505. This send rate is determined ac- 
cording to the reproduction rate of the client 508 and the 
capacity available for transfer of the network. The 
stream data stored in the transmission buffer 504 is read 
out at said prescribed send rate based on the control of 
the rate controlling means 505 and transferred to the 
packet transmitting means 502, and the packet trans- 
mitting means 502 sends out this stream data to the net- 
work 507 by incorporating it in packets. 

On the other hand, the client 508 is constructed as 
described below. Namely, the data packets received 
from the network 507 are received by the packet receiv- 
ing means 509, and the packets are disassembled here 
to be stored on the receiving buffer 511 one after anoth- 
er. The data reproducing means 512 reads out the data 
stored on the receiving buffer 511 as above sequentially 
at prescribed reproducing ate and delivers it to a display 



unit. 

To control the start of transfer, a transfer start re- 
questing means 517 is provided on the client 508 side, 
and this transfer start requesting means 517 issues a 

s request for start of transfer according to the operator's 
instructions. This request for start of transfer is delivered 
to the packet transmitting means 510, incorporated into 
transfer start request packets here, and transferred to 
the server 500 through the network 507. As a result, the 

10 start request processing means 516 of the server 500 
starts the rate controlling means 505 to start data trans- 
fer as described above. 

Such procedure is repeated for thp transfer of 
stream data between the server and the client. However, 

15 a computer network generally produces a certain 
amount of packet loss depending on the state of the net- 
work concerned, while packet loss is produced in case 
of occurrence of an overflow of the receiving buffer due 
to shortage of processing capacity of the client's com- 

20 puter, or fluctuation of reproducing ate of stream data, 
etc. 

Therefore, also on said conventional system, an ar- 
rangement is made for compensation in such case of 
data loss. 

25 Namely, the loss rate reporting means 513 of the 
client 508 constantly monitors the receiving buffer 511 
and, in case of occurrence of any data loss, reports data 
loss rate to the packet transmitting means. The packet 
transmitting means 510 prepares a rate change request 

oo packet including an address of the server 500, an iden- 
tifier to the effect that it is a send rate change request 
packet, and said loss rate, and then transmits the packet 
to the network. 

The rate change request packet sent out this way 

35 is received by the packet receiving means 501 of the 
server 500, is identified as a rate change request packet 
here, and then is delivered to the rate changing means 
506. This rate changing means 506 is provided, in the 
form of a table, with send rates corresponding the loss 

40 rate on said client 508 contained in said rate change re- 
quest packet lor example, and the rate changer 506 de- 
termines a new send rate by referring to this table, and 
transfers that send rate to the rate controlling means 
505. Upon receipt of this transfer, the rate controlling 

45 means 505 reads out the stream data from the trans- 
mission buffer 504 by lowering( or raising) send rate and 
delivers it to the packet transmitting means 502. 

However, in such conventional stream data transfer 
system, the send rate from the server 500 is lowered 

50 only after any loss of data is detected by the client 508 
as described above. Therefore there is no way to repro- 
duce any data once lost. In addition, the images fluctu- 
ates in case any data partly lost is reproduced. 

Fig. 15 shows a method to transfer data other than 

55 stream data such as text data, for example, from the 
server 500 to the client 508. Namely, each time when 
data "Data" in units of prescribed size is transferred from 
the server 500 to the client 508, an acknowledgement 
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• 

signal "Ack" is returned from the client 508 to the server 
500 and, upon receipt of this acknowledgement signal 
n Ack n ,/the server sends out a new data "Data 0 . 

According' to this method, the client 508 does not 
return the acknowledgement signal "Ack" when it re- 
ceived a data with loss, making it impossible for the serv- 
er to send, out the next "Data". In this state, a shortage 
of data is produced on the receiving buffer 511 because 
the next data is not transferred until a prescribed time 
To elapses, for example. As a result, the image stops or 
fluctuates. 

The object of the present invention, proposed in 
view of said defects of the conventional stream data 
transfer system, is to provide a more reliable stream da- 
ta transfer method and a system, by lowering the send 
rate from the server before any loss of data is produced 
on the buffer of the client. Another object of the pesent 
invention is to provide a stream data transfer method 
and a system that transmits the lost data again even 
there is data is lost in the buffer of the client. 

Yet another object of the present invention is to pro- 
vide a stream data transfer method and its system, ca- 
pable of effectively achieving said object, even in a mul- 
ticast transfer system for transferring one same data to 
a plural number of clients simultaneously from the serv- 
er. 

SUMMARY OF THE INVENTION 

The present invention adopts the means described 
below to achieve said objects. First, the stream data 
transfer system of the present invention comprises a 
server 400 and a client 470 as described below. In said 
server 400 the stream data read out from the storing 
means (storing device 403 and transmission buffer 404 
in Fig. 1) at prescribed rate based on the control of the 
rate controlling means 405 are incorporated into data 
packets at the packet transmitting means 402. Next, the 
packets are transmitted to the client 470 through the net- 
work 300. The packet receiving means 401 receives re- 
quest from the client 470. 

Moreover, said client 470 receives, with the packet 
receiving means 410, the stream data sent out at pre- 
scribed rate from said server 400 through the network 
300, stores it once on the receiving buffer 412 and re- 
produces it, and sends out necessary instruction to said 
server 400 from the packet transmitting means 411. 

In said system, the present invention makes a re- 
quest for change of rate from the client 470 in corre- 
spondence to the state of vacancy of said receiving buff- 
er 412, and changes the send rate on the server 400 
based on that request for change of rate. 

To be concrete, a rate change requesting means 
413 is provided on the client 470 side, to monitor the 
vacant capacity of the receiving buffer 412, and make a 
request for change of rate conformable to that vacant 
capacity. On the other hand, a rate change request in- 
hibiting means 416 is provided on the server 400, to re- 
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new the send rate set on said rate controlling means 
405, in response to the request for change of rate issued 
by the client 470 as described above. 

This prevents any overflow of stream data from the 
s receiving buffer 41 2. 

Furthermore, based on the re-transfer request is- 
sued from the client 470 in correspondence to the loss 
of stream data received by said packet receiving means 
41 0, the storing means on the server 400 sends out data 
10 corresponding to the lost data concerned. 

To be concrete, a re-transfer requesting means 414 
is provided on the client 470, to monitor loss of the data 
received by said packet receiving means 4i0, and make 
a request for re-transfer of the data corresponding to the 
75 lost data concerned. On the other hand, a re-transfer 
controlling means 407 is provided on the server 400, to 
perform re-transmission of the stream data correspond- 
ing to the lost data. 

This makes it possible to compensate for the loss 
20 jn case of occurrence of any data loss. 

The present invention can be used independently 
with a construction necessary for said change of rate, 
and can be used independently with a construction for 
re-transfer, and can also be realized with a construction 
25 combining said 2 different types of processing. 

By the way, in the case where said method is directly 
applied to a multicast transfer system capable of trans- 
ferring one same data to a plural number of clients at a 
time, the server must cope with a plural number of re- 
30 quests from the respective clients constituting the mul- 
ticast. 

This means an increased load for the server and 
the network and, therefore, said method cannot be di- 
rectly applied to a multicast transfer system. 

35 For that reason, the present invention is realized in 
a way to issue, in correspondence to the state of vacan- 
cy of the receiving buffer of a specific client 41a belong- 
ing to the same multicast group, a request for change 
of rate from that specific client 41a to said server 400, 

40 and change the send rate of said server 400 based on 
that request for change of rate. 

To be concrete, a rate change requesting means 
41 3 is provided on a specific client 41 a belonging to the 
same multicast group, to monitor the vacant capacity of 

45 said receiving buffer 412, and to make a request for 
change of rate corresponding to the vacant capacity to 
said server. 

On the other hand, a rate change controlling means 
406 is provided on the server 400, to renew the send 
50 rate set on said rate controlling means 405, in corre- 
spondence to said request for change of rate. 

This makes it possible to avoid overflow of multicast 
stream data at the receiving buffers of the clients, while 
controlling increase of load on the server 400 and the 
ss network 300. 

Still more, the present invention can also be real- 
ized in a way to issue, in correspondence to the loss of 
stream data received by the packet receiving means 
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410 of a specific client 41a belonging to said one same 
multicast group, a request for re-transfer from that spe- 
cific client 41a to said server 400, and send out data 
corresponding to the lost data concerned from the stor- 
ing means of said server 400. 

To be concrete, the present invention will be con- 
structed by providing a re-transfer requesting means 
414 on a specific client 41a belonging to said one same 
multicast group, and providing a re-transfer controlling 
means 407 on said server 400. In this construction, it is 
so arranged that said re-transfer requesting means 414 
monitors loss of the data received by said packet receiv- 
ing means 410, and makes a request for re-transfer of 
the data corresponding to the lost data concerned to 
said server 400, while said re-transfer controlling means 
407 makes a re-transfer of the stream data correspond- 
ing to said lost data, based on said request for re-trans- 
fer. 

This makes it possible to compensate for the loss 
even in case of occurrence of any data loss, while con- 
trolling increase of load on the server and the network. 

Yet more, it is so arranged that said specific client 
41a issues said request for change of rate to said server 
400 and all clients belonging to said one same multicast 
group. In this state, issuance of request for change of 
rate issued by other specific client by other specific client 
identical to the request for change of rate issued by said 
specific client is prohibited for a prescribed time set in 
advance. Or in the case where said server received one 
same request for change of rate from a plural number 
of clients within a prescribed time set in advance, it is 
possible to validate one of those requests for change of 
rate, and change the send rate of the server based on 
that request for change of rate. 

To be concrete, said specific client 41a is provided, 
as shown in Fig. 9, with a rate change request inhibiting 
means 415 for inhibiting issuance of request for change 
of rate identical to the request for change of rate issued 
by other specific client for a prescribed time. Or, as 
shown in Fig. 10, said server 400 comprises the same 
rate change request processing means 408 for deter- 
mining, in the case where the server 400 received one 
same said request for change of rate from a plural 
number of clients within a prescribed time set in ad- 
vance, one of those requests for change of rate as valid. 

Moreover, it is possible to issue said request for re- 
transfer from said specific client 41a to said server 400 
and to all clients belonging to said one same multicast 
group, and inhibit issuance of request for re-transfer 
identical to said request for re-transfer from other spe- 
cific client for a prescribed time set in advance. Or, it is 
possible to determine, in the case where said server 400 
received one same said request for re-transfer from a 
plural number of clients within a prescribed time set in 
advance, one of those requests for re-transfer as valid, 
and send out data corresponding to the lost data from 
the storing means of said server 400. 

To be concrete, said specific client 41a is provided, 



as shown in Fig. 9, with a re-transfer request inhibiting 
means 416 for inhibiting issuance of request for re- 
transfer identical to the request for re-transfer issued by 
other specific client for a prescribed time. Or, as shown 

5 in Fig. 10, said server 400 is constructed by comprising 
a one same re-transfer request processing means 409 
for determining, in the case where the server 400 re- 
ceived one same said request for re-transfer from a plu- 
ral number of clients within a prescribed time set in ad- 

10 vance, one of those requests for re-transfer as valid. 

By said procedure, it becomes possible to restrict 
the load on said server 400 and network 300. 

Furthermore, before transmission of stream data 
said server 400 determines whether one client can co- 

is existe with the other clients included in the same group 
or not after obtaining conditions to issue a request for 
changning of rate from each client. When the server 400 
determines that the client cannot coexist in one same 
multicast group, it is possible for the server 400 to trans- 

20 fer the data to the client by other multicast group. Or 
when client has conditions with difficulty of coexistence 
in one same multicast group it is also possible for said 
specific client to receive the data as other multicast 
group. 

2S To be concrete, said server 400 is provided, as 
shown in Fig. 11, with a transmission destination group 
split controlling means 41 8, to control in a way to transfer 
the data by other multicast group to said client having 
conditions with difficulty of coexistence in one same 

30 multicast group. In addition, said specific client is pro- 
vided, as shown in Fig. 12, with a group split controlling 
means 41 9, to receive the data by other multicast group, 
in the case where that specific client has conditions with 
difficulty of coexistence in one same multicast group. 

35 For that reason, clients having conditions enabling 
coexistence are made to belong to one same multicast 
group, to distribute stream data under separate multi- 
cast addresses to the respective multicast groups. 
Therefore, it becomes possible to improve the reliability 

40 of data transfer to a larger number of clients. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a construction drawing of one embodiment 
45 of the present invention. 

Fig. 2 is a flow chart showing the procedure of the 
present invention. 

Fig. 3 is a flow chart showing the procedure of the 
present invention. 
50 Fig. 4 is a conceptual drawing showing position 
numbers on the file. 

Fig. 5 is a conceptual drawing showing the data ar- 
rangement on the receiving buffer. 

Fig. 6 is a conceptual drawing showing various 
55 types of packet structure used for the present invention. 

Fig. 7 is a block diagram of one embodiment of the 
present invention. 

Fig. 8 is a conceptual drawing showing various 
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types of packet structure used for the present invention. 

Fig. 9 is a block diagram of other embodiment of the 
present invention. 

Fig. 1 0 is a block diagram of other embodiment of 
the present invention. 

Fig. 11 is a block diagram of other embodiment of 
the present invention. 

Fig. 12 is a block diagram of other embodiment of 
the present invention. 

Fig. 1 3 is a conceptual drawing showing a form of 
embodiment of the present invention by portable medi- 
um. 

Fig. 14 is a block diagram of the stream data trans- 
fer system in a conventional example. 

Fig. 15 is a conceptual drawing showing an exam- 
ple of trouble by the conventional method. 

EMBODIMENTS OF THE INVENTION 

(EMBODIMENT 1) 

Fig. 1 shows an embodiment of the stream data 
transfer system according to the present invention. The 
construction of the system according to the present in- 
vention will be explained hereafter together with its pro- 
cedure based on Fig. 1 . 

This system is identical to said conventional system 
in that the server 400 and the client 470 are connected 
to each other through of a network 300. 

As the operator gives an instruction for the transfer 
of a specific file by using input means such as keyboard, 
or cursor, etc. and displayed picture, the transfer start 
requesting means 480 of the client 470 notifies the pack- 
et transmitting means 411 of the request for start and, 
upon receipt of this notification, the packet transmitting 
means 411 sends out, as shown in Fig. 6 (d), a transfer 
request packet carrying transmitter's address (1), trans- 
mission destination address (2), packet type identifier 
(request for start of transfer) (3), matters identifying the 
file (file name or file number) (7) and, as required, trans- 
fer start position number (8), to the network 300. 

Said transfer start position number, generated by 
the rate controlling means 405 on the server 400 as de- 
scribed later, is a number indicating the position on the 
file of the data concerned other than the packet number 
attached to the data packet transmitted by the packet 
transmitting means 402, and is required for the re-trans- 
fer described later. Namely, it is a number corresponding 
to the readout starting position among the numbers as- 
signed one after another (expressed with a suffix T) to 
the sections formed by partitioning, as shown in Fig. 4, 
said specified file F into units of specific bytes [number 
of bytes corresponding to 1 packet, lor example (1kb, 
for example)]. And this number is of course 0 in the case 
where the file is read out from its head but indicates the 
number corresponding to the position concerned when 
the readout starts on the way. However, the operator 
specifies the transfer start position at a value which can 



be understood by the operator such as time required for 
reaching the readout start position from the head, for 
example, and this value is converted into said section 
number by said transfer start requesting means 480, al- 

s though this position number, which must be incorporat- 
ed in said data packet in the case of re-transfer to be 
described later, needs not be incorporated in said data 
packet in the case without re-transfer. 

The transfer request packet sent out to the network 

10 300 this way is received by the packet receiving means 
401 of the server 400, judged here by said packet type 
identifier (3) as being a transfer request packet, and 
transferred to the start request processing means 417. 
Upon receipt of this transfer, the start request process- 
es ing means 417 delivers the matters (7) identifying the 
file such as file name, file number, etc. and the transfer 
start position number (8) specified as above to the rate 
controlling means 405, and starts this rate controlling 
means 405. At this, the rate controlling means 405 reads 

20 out the stream data from the address corresponding to 
said transfer start position number (8) in the storing de- 
vice 403 one after another, and once stores that data in 
the transmission buffer 404. 

In said rate controlling means 405 are set a send 

25 rate determined depending on the reprodution rate of 
the client 470 described below and the capacity availa- 
ble for transmission of the network 300. 

And the stream data stored in the transmission buff- _ 
er 404 as above is read out from the transmission buffer 

30 404 at said send rate and transferred to the packet trans- 
mitting means 402. The packet transmitting means 402 
incorporates the stream data obtained this way in a data . 
packet and sends it out to the network 300. This data 
packet carries, as shown in Fig. 6 (a), address of trans- 

35 mitter (address of server 400) (1), transmision destina- 
tion address (address of client 470) (2), packet identifier 
of being a data packet (3), data size (4) and packet 
number showing the order of packet (5) placed on the 
header, followed by the actual data. 

40 To provide the system with a re-transfer function, 
information identifying the position on the file formed in 
the rate controlling means 405 in addition to said packet 
number, such as section number (position number) in 
the case where the file explained above by using Fig. 4 

45 js partitioned into a prescribed size. Said packet number 
and this position number agree with each other in the 
case where the file is read out from the head of file and 
that the capacity unit of said 1 section agrees with the 
capacity unit of 1 packet, but they do not agree in the 

50 case where the two capacities are different or when the 
data is read out from the file as above halfway (See Fig. 
5). 

The data packet sent out to the network 300 as 
above is received by the packet receiving means 410 of 
55 the client 470, judged here by the packet identifier (3) 
of packet type as being a data packet, and is stored on 
the prescribed address on the receiving buffer 41 2, with 
reference to said packet number and the packet size. 
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Here, the packet receiving means 410 controls the 
packet number (5) attached by the packet transmitting 
means 402 on the server 400 as above, and the order 
of packets is duly controlled at the packet receiving 
means 4)0, even it the numbers of the packets arriving 
at the packet receiving means 41 0 one after another get 
out of order for some reason or another. 

Moreover, the stream data transferred without 
omission of packet is stored on the receiving buffer 41 2 
without vacancy as shown in Fig. 5 (a) in correspond- 
ence to the respective packet numbers. However, in 
case there is any loss of packet, the stream data is 
stored on the receiving buffer 41 2 with a vacant area as 
shown in Fig. 5 (b). Numbers having a suffix "p" in Fig. 
5 are packet numbers, while numbers with a suffix T 
are position numbers on the file and, for making a re- 
transfer as explained later, the packet receiving means 
410 of the client 470 not only controls the packet num- 
bers as above but also has a function of controlling the 
position numbers of said file. 

Fig. 5 shows an example in which, while the packet 
number gradually increases from 0, the position number 
on the file starts from on the way (300th position). Name- 
ly, it corresponds to a case where the file is read out not 
from the head but from on the way. 

The data stored on the receiving buffer 412 as 
above is read out and reproduced by the data reproduc- 
ing means 490 at prescribed reproducing ate. The re- 
producing ate, though variable in time in some cases 
depending on the type of image, should be set in a way 
to maintain an equilibrium between said send rate and 
reproduction rate as a matter of course. Moreover, since 
it is necessary to avoid, at this time, a state in which the 
data reproducing means 490 gains access to the receiv- 
ing buffer 412 in the state without data on the receiving 
buffer 412, it is so arranged that reproducing starts from 
a state in which a certain amount of data is stored in the 
receiving buffer 412. 

While the transfer of stream data is made between 
the server and the client with repetition of the procedure 
described above, said processing is exactly the same 
as the procedure in a conventional system, except for 
the description regarding the information (position 
number) identifying the position on the file. 

In the case where, in the above operation, an equi- 
librium is established between the send rate of the pack- 
et transmitting means 402 on the server 400 side and 
the reproducing ate of the data reproducing means 490 
on the client 470, the vacant area on the receiving buffer 
412 is maintained at a constant value. However, there 
are cases where the vacant capacity on the receiving 
buffer 41 2 diminishes lor reason of shortage of process- 
ing capacity of computer on the client 470, or fluctuation 
of reproducing ate of stream data, etc. If that state con- 
tinues, the receiving buffer 412 overflows, producing 
loss of data. In that case, the send rate on the server 
400 side is changed as described below. 

Namely, the rate change requesting means 413 of 



the client 470 constantly monitors the vacant capacity 
of the receiving buffer 412 and, when it detected a de- 
crease of vacant capacity from prescribed set value 
(20% of the total capacity of receiving buffer, for exam- 
5 pie), notifies the packet transmitting means 411 of a re- 
quest for change of rate for lowering the send rate to- 
gether with the requested rate. Upon receipt of this no- 
tification of rate change request, the packet transmitting 
means 411 sends out a rate change request packet in- 
fo corporating, as shown in Fig. 6 (b), address of transmit- 
ter (address of client 470) (1), address of transmission 
destination (address of server) (2), packet identifier of 
being a rate change request (3), and requested rate (6), 
to the network 300 (see Fig. 2, steps S21 to S22 to S25). 
is The packet receiving means 401 of the server 400 
receives said rate change request packet from the net- 
work 300, judges it to be a rate change request packet 
from its identifier, and delivers its contents to the rate 
change request processing means 406. At this, the rate 
20 change request processing means 406 delivers a new 
send rate to the rate controlling means 405 to request 
lowering of the send rate, and the rate controlling means 
405 reads out the stream data from the transmission 
buffer 404 by lowering the send rate and delivers it to 
25 the packet transmitting means 402. 

In this way, as the send rate of data packet is low- 
ered, the vacant capacity in the receiving buffer 412 
gradually increases. However, since this situation is also 
monitored by said rate change requesting means 41 3, 
30 said rate change requesting means 413 notifies the 
packet transmitting means 411 of a request for change 
of rate for raising the send rate in the case where the 
vacant capacity increased beyond a prescribed value 
(80% of the total capacity of the receiving buffer, for ex- 
35 ample), and the packet transmitting means 411, upon 
receipt of this notification, performs the same process- 
ing as above to prepare a rate change request packet 
and transmits it to the network 300 (see Fig. 2, steps 
S23 to S24 to S25). 
40 The packet receiving means 401 of the server 400 
receives said rate change request packet from the net- 
work 300 and, in the same way as in the change of rate 
in the case of lowering said send rate, the rate change 
request processing means 406 delivers the requested 
45 send rate to the rate controlling means 405, and the rate 
controlling means 405 makes a transmission at the in- 
creased send rate. 

By proceeding as described above, the transfer rate 
of the stream data is lowered before the receiving buffer 
50 412 of the client 470 overflows, preventing occurrence 
of loss of data, and the send rate of the stream data is 
raised before any shortage of stream data stored in the 
receiving buffer 412 of the client 470 is produced, thus 
making it possible to store the stream data in the receiv- 
es ing buffer 412 without loss. 

While in the above example the send rate is deter- 
mined on the client 470 side, it is possible to output only 
the rate change request and the vacant capacity (indi- 
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cated with % of the total capacity of the receiving buffer, 
for example) of the receiving buffer 412 from the client 
470, and set the actual send rate in the rate controlling 
means 405 by determining the send rate corresponding 
to said vacant capacity at the rate change request 
processing means 406 on the server 400 side. 

Moreover, while in the above explanation the send 
rate is lowered when the vacant capacity of the receiving 
buffer 412 dropped to no more than a prescribed value 
and raised when the vacant capacity increased to over 
the prescribed value, it may be al) right, as another meth- 
od, to stop the send from the server 400 by putting the 
send rate to 0 when the vacant capacity of the receiving 
buffer 412 dropped under a prescribed value (20%, for 
example), and return the send rate to the prescribed val- 
ue when the vacant capacity increased to no less than 
the prescribed value (over 80%, for example). 

Even with adjustment of send rate as above, there 
are cases where loss of data packet is produced for 
some reason or another such as situation of network 
300, etc. and there are also cases where loss of data 
packet is produced because of some external factor 
such as noise, etc. 

For that reason, it is so arranged that the re-transfer 
requesting means 414 detects whether or not any loss 
as shown in Fig. 5 (b) is produced in the stream data 
stored in the receiving buffer 412 of the client 470. In 
reality, the re-transfer requesting means 414 constantly 
monitors the packet receiving means 410 and, in case 
of any loss of position number (suffixed with T in Fig. 
5), calculates the position number corresponding to the 
lost packet from the position numbers before and after 
that number. The position number calculated this way is 
informed to the packet transmitting means 411 together 
with the re-transfer request requesting re-transmission 
of data. 

The packet transmitting means 41 1 , upon receipt of 
said re-transfer request, sends out a re-transfer request 
packet indicated in Fig. 6 (c) carrying transmitter's ad- 
dress (address of client) (1), transmission destination 
address (address of server) (2), packet type identifier 
(re-transfer request) (3), position number regarding re- 
transfer request (9) and size of data to be re-transferred 
(4) to the network 300 (see Fig. 3, steps S31 to S32 to 
S33). 

The re-transfer request packet sent out to the net- 
work 300 this way is received by the packet receiving 
means 401 of the server 400, judged here as being a 
re-transfer request packet, and the contents of this 
packet are informed to the re-transfer controlling means 
407. Upon receipt of this notification, the re-transfer con- 
trolling means 407 reads out stream data of prescribed 
size from the transmission buffer 404 according to the 
position number included in the re-transfer request and 
delivers it to the packet transmitting means 402. 

The packet transmitting means 402, in the same 
way as for ordinary data transfer, incorporates the re- 
ceived data in the data packet indicated in Fig. 6 (a) and 



sends it out to the network 300. 

As described above, the packet receiving means 
410 controls the packet number corresponding to the 
data stored in the receiving buffer 412 and the position 
5 number on said file. In the case where, in this state, a 
data packet is received by the packet receiving means 
410, the packet receiving means 410 calculates the ad- 
dress on the receiving buffer 41 2 where to store the da- 
ta, from the position number on said file attached to the 
10 packet concerned, and inserts it at the address where 
the data is lost. 

By proceeding this way, this system can perform re- 
transf er at high speed even in case of occurrence of any 
loss of packet in the network, thus preventing loss of 
is data. 

Time information from the start point of the file can 
be used in place of the position number incorporated in 
the packet header as explained above. 

Moreover, it is possible to manage packet numbers 
20 and position numbers coresponding to the data to be 
transmitted by the re-transfer controlling means 407 in 
the server 400. And it is possible for re-transfer request- 
ing means 41 4 to issue the re-transfer request including 
the packet number. 
2S As described above, according to the data transfer 
method of this embodiment, no loss of data is produced 
even in case of occurrence of any shortage of process- 
ing capacity of client, fluctuation of reproducing ate of 
stream data, etc. and, moreover, the transfer of stream 
30 data can be made without loss of data even in case of 
loss of packet in the network. 

(EMBODIMENT 2) 

35 By the way, when transferring one same data to a 
plural number of clients at a time, multicast transfer sys- 
tem is used in some cases. Namely, by defining one 
group in advance and register the clients to be destina- 
tions of transfer in that group, the server can transfer 

40 data to all registered clients belonging to the group. This 
makes it possible to transfer one same data to a plural 
number of clients efficiently, with no need of transferring 
the data individually to each object client from the server. 
However, in the case where said embodiment is ap- 

45 plied as it is to a multicast system, a case is produced 
where all clients constituting a specific multicast send 
said rate change request packet or said re-transfer re- 
quest packet to the server, for example. In such a case, 
the load on the server and the network becomes exces- 

50 sively high, presenting a risk of occurrence of other trou- 
ble such as a phenomenon of interruption of display due 
to absence of data in the buffer on the client side, for 
example. 

For that reason, the present embodiment proposes 
55 a construction in which said embodiment effectively 
works, even with a multicast type system. 

Fig. 7 is a block diagram showing one embodiment 
of the multicast stream data transfer system according 
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to the present invention. The system construction of the 
present invention will be explained hereafter together 
with its procedure based on Fig. 7. 

In.Fig. 7, the multicast group is composed of a serv- 
er 400 on. the 'side providing data, a client (hereinafter 
referred to as "requesting client") 41 a provided with rate 
change request function and re-transfer request func- 
tion on the side receiving the supply of data, and clients 
(hereinafter deferred to as "ordinary clients") 42a, 42b, 
— not provided with rate change request function and 
re-transfer request function also on the side receiving 
the supply of data, and a network 300 intervenes be- 
tween said server 400 and the requesting client 41 a and 
the ordinary clients 42a, 42b, — . However, it is also pos- 
sible to have said requesting client in a plural number 
as required. 

Namely, while said requesting client 41a is provid- 
ed, in the same way as the client 470 indicated in Fig. 
1 , with at least one of rate change requesting means 
413 and re-transfer requesting means 414, the ordinary 
clients 42a, 42b, — are not provided with them. 

In said construction, at an instruction for start of data 
transfer by the operator, etc. at said server 400 or a re- 
quest for start of transfer, etc. from a requesting client 
41a, the start request processing means 417 delivers 
matters identifying a file such as file name, file number, 
etc. to the rate controlling means 405, and starts that 
rate controlling means 405. At this, the rate controlling 
means 405 reads out the stream data from the specified 
address in the storing device 403 one after another, and 
once stores that data in the transmission buffer 404. 

After that, data transfer is executed between the re- 
questing client 41a and the server, but explanation on 
this data transfer is omitted here because its procedure 
is exactly the same as the contents described in the ex- 
planation of said Fig. 1 . However, since this embodiment 
is applied to a multicast system, the stream data from 
the server is transferred not only to the requesting client 
41a but also to said ordinary clients 42a, 42b, — at the 
same time. 

The procedure of issuing a rate change request in 
the case where the vacant capacity of the receiving buff- 
er 412 of the requesting client 41a became lower than 
the prescribed value (higher than the prescribed value) 
is the same as the procedure explained in Fig. 2 and, 
therefore, explanation on this procedure will be omitted 
here. Moreover, the procedure of issuing a re-transfer 
request in case of occurrence of a loss of the stream 
data received by the requesting client 41a is also the 
same as the procedure explained in said Fig. 3 and, 
therefore, explanation on it will be omitted here. In this 
embodiment, which is constructed in such a way that 
only the requesting client 41a is provided with a rate 
change requesting means 413 and a re-transfer re- 
questing means 41 4, the right of issuing said request for 
re-transfer and the right of issuing said request for 
change of rate are given only to the requesting client 
41a. However, when said request for change of rate is 



issued by the requesting client 41a, the data transfer 
rate to all clients constituting the multicast is changed, 
in addition, in the case where any specific data packet 
is transferred again in response to said request for re- 

s transfer, that packet is received by all clients constituting 
the multicast. 

Furthermore, while the data packet (Fig. 8 (a)), rate 
change request packet (Fig. 8 (b)), and re-transfer re- 
quest packet (Fig. 8 (c)) used here are about the same 

10 in contents as the respective packets indicated in Fig. 
6, multicast address (address common to a plural 
number of clients constituting a multicast) is used as 
transmission destination address. , 

Next, Fig. 9 is a block diagram showing other em- 

15 bodiment of the multicast stream data transfer system 
according to the present invention. The system con- 
struction of the present invention will be explained here- 
after together with its procedure based on Fig. 9. Expla- 
nation will be omitted on the construction and procedure 

20 identical to those in said embodiment. 

In the case where a rate change request is issued 
by the rate change requesting means 433 of the re- 
questing client 41b, the packet receiving means 431 
which received notification of this rate change request 

25 sends out, for the server and all clients receiving data 
in one same multicast group, a rate change request 
packet carrying, as shown in Fig. 8 (b), transmitter's ad- 
dress (address of requesting client 41 b) (1 ), address of 
multicast (2), packet identifier of being a data change 

30 request packet (3), and requested rate (6), to the net- 
work 300. 

The packet transmitting means 411 of the request- 
ing client 41a receives said rate change request packet 
from the network 300, judges it to be a rate change re- 

35 quest packet from its identifier and notifies the rate 
change request inhibiting means 41 5 of the contents of 
that packet. At this notification, the rate change request 
inhibiting means 41 5 prohibits said rate change request- 
ing means 413 to issue any rate change request of the 

40 same contents as those of said rate change request for 
a prescribed time set in advance. The processing based 
on said rate change request packet from the requesting 
client 41b received by said server 400 is the same as 
that in said embodiment. Moreover, the processing is 

45 the same as that in said embodiment also in the case 
where a rate change request is issued by the rate 
change requesting means 413 of the requesting client 
41a. Furthermore, said rate change request packet also 
reaches the ordinary client 429, but this point will be ig- 

50 nored here because the ordinary client 429 has no rate 
change request lunction. 

Next, in the case where a request for re-transfer is 
issued by the re-transfer requesting means 434 of the 
requesting client 41b, the packet receiving means 431 

55 which received notification of this re -transfer request 
sends out, for the server and all clients receiving data 
in one same multicast group, a re-transfer request pack- 
et carrying, as shown in Fig. 8 (c), transmitter's address 
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(address of requesting client 41b) (1 ), address of multi- 
cast (2), packet type identifier (re-transfer request) (3), 
position number concerning the re-transfer request(9), 
and size,data'to be re-transferred (4), to the network 
300. - 

The packet transmitting means 411 of the request- 
ing cfient 41a receives said re-transfer request packet 
from the network 300, judges it to be a re-transfer re- 
quest packet from its identifier and notifies the re-trans- 
fer request inhibiting means 416 of the contents of that 
packet. The re-transfer request inhibiting means 416 
prohibits said re-transfer requesting means 434 to issue 
any re-transfer request of the same contents as those 
of said re-transfer request for a prescribed time set in 
advance. The processing based on said re-transfer re- 
quest packet from the requesting client 41 b received by 
said server 400 is the same as that in said embodiment. 
Moreover, the processing is the same as that in said em- 
bodiment also in the case where a rate change request 
is issued by the rate change requesting means 413 of 
the requesting client 41a. Furthermore, in the same way 
as in the case said rate change request, said re-transfer 
request packet also reaches the ordinary client 42a, but 
this point will be ignored here because the ordinary cli- 
ent 42a has no re-transfer request function. 

As described above, the load on said server 400 
and the network 300 can be controlled with no issuance 
of any rate change request of one same contents as 
those of the rate change request already transmitted by 
other requesting client and with no issuance of any re- 
transfer request of one same contents as those of the 
re-transfer request already transmitted by other re- 
questing client. 

Fig. 10 is a block diagram showing other embodi- 
ment of the multicast stream data transfer system ac- 
cording to the present invention. The system construc- 
tion of the present invention will be explained hereafter 
together with its procedure based on Fig. 10. Explana- 
tion will be omitted on the construction and procedure 
identical to those in said embodiment. 

In the case where the requesting clients 41a 41b- 
transmitted a rate change request packet, the packet re- 
ceiving means 401 of the server 400 receives said rate 
change request packet from the network 300, judges it 
to be a rate change request packet from its identifier, 
and notifies the one same rate change request process- 
ing means 408. The one same rate change request 
processing means 408 validates the rate change re- 
quest received in the first place among the rate change 
requests notified within a prescribed time set in ad- 
vance, and delivers its contents to the rate change re- 
quest processing means 406. For example, in the case 
where one same rate change request was received from 
said requesting client 41a and requesting client 41b 
within said prescribed time set in advance (suppose that 
the rate change request from said requesting client 41 a 
was received first here), the one same rate change re- 
quest processing means 408 validates the rate change 
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request from said requesting client 41a and delivers its 
contents to the rate change request processing means 

406, while treating the rate change request from said 
requesting client 41 b as invalid. At this, the rate change 

5 request processing means 406 delivers a new send rate 
to the rate controlling means 405 based on the rate 
change request from said requesting client 41a, and the 
rate controlling means 405 reads out the stream data 
from the transmission buffer 404 at the new send rate 

io and delivers it to the packet transmitting means 402. 

Next, in the case where the requesting clients 41a 
41 b-transmitted a re-transfer request packet, the pack- 
et receiving means 401 of the server 400 receives said 
re-transfer request packet from the network 300, judges 

is it to be a re-transfer request packet from its identifier, 
and notifies the one same re-transfer request process- 
ing means 409. The one same re-transfer request 
processing means 409 validates the re-transfer request 
received in the first place among the re-transfer re- 

20 quests notified within a prescribed time set in advance, 
and delivers its contents to the re-transfer control means 

407. For example, in the case where one same re-trans- 
fer request was received from said requesting client 41a 
and requesting client 41 b within said prescribed time set 

25 in advance (suppose that the re-transfer request from 
said requesting client 41a was received first here), the 
one same re-transfer request processing means 409 
validates the re-transfer request from said requesting 
client 41a and delivers its contents to the re-transfer 

30 control means 407, while treating the re-transfer request 
from said requesting client 41 b as invalid. At this, the re- 
transfer control means 407 reads out the stream data of 
prescribed size from the transmission buffer 404 ac- 
cording to the position number included in the request 

35 for re-transfer from said requesting client 41 a and deliv- 
ers it to the packet transmitting means 402. 

As described above, it becomes possible to control 
the load on said server 400 and the network 300 by treat- 
ing rate change requests of one same contents as a sin- 

40 gle rate change request and also treating re-transfer re- 
quests of one same contents as a single rate change 
re -transfer request. 

By the way, even among clients registered in one 
same multicast group, there exist clients having difficulty 

45 of coexistence in one same multicast group, because of 
differences in the ability of individual clients, such buffer 
capacity, buffer processing speed, etc., for example. Ex- 
planation will be given hereafter on a construction in 
which said embodiments effectively works even in such 

50 a case. 

Fig. 11 is a block diagram showing other embodi- 
ment of the multicast stream data transfer system ac- 
cording to the present invention. The system construc- 
tion of the present invention will be explained hereafter 
55 together with its procedure based on Fig. 11. Explana- 
tion will be omitted on the construction and procedure 
identical to those in said embodiment. 

The requesting clients 41a, 41b, — transmit, by ei- 
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ther an instruction for transfer of rate change conditions 
by operator, etc. at said server 400 or voluntary trans- 
mission from the requesting clients 41a, 41b — , a con- 
dition notification packet for notifying the conditions of 
rate change request. The conditions for issuing said rate 
change request to be notified by this condition notifica- 
tion packet here are buffer capacity, buffer processing 
speed, etc., for example. Next, the packet receiving 
means 401 of the server 400 receives said condition no- 
tificatipn packet from the network 300, judges it to be a 
condition notificaiion packet from its identifier, and de- 
livers its contents to the transmission destination group 
split controlling means 418. 

The transmission destination group split controlling 
means 418 judges if coexistence is possible or not in 
the multicast group to which the respective requesting 
clients currently belong. Here, the transmission destina- 
tion group split controlling means 418 controls as as to 
transfer the data by other multicast group to clients hav- 
ing conditions with difficulty of coexistence in one same 
multicast group based on the rate change conditions 
transmitted from respective requesting clients. And then 
the rate controlling means 405 is notified of the send 
rate by that other multicast group. 

The rate controlling means 405 reads out the 
stream data from the transmission buffer 404. It then de- 
livers the data to the packet transmitting means 402, at 
a specific send rate conformable to the conditions con- 
cerned for requesting clients having conditions enabling 
coexistence in one same multicast group, and at said 
notified other send rate for said other multicast group. 

Fig. 12 is a block diagram showing other embodi- 
ment of the multicast stream data transfer system ac- 
cording to the present invention. The system construc- 
tion of the present invention will be explained hereafter 
together with its procedure based on Fig. 12. Explana- 
tion will be omitted on the construction and procedure 
identical to those in said embodiment. 

Before transmission of stream data, the respective 
requesting clients 41b, — transmit a condition notifica- 
tion packet for notifying the conditions of rate change 
request. The conditions for issuing said rate change re- 
quest to be notified by this condition notification packet 
here are buffer capacity, buffer processing speed, etc., 
for example, in the same way as in said embodiment. 
Next, the packet receiving means 410 of the requesting 
client 41a receives said condition notification packet 
from the network 300, judges it to be a condition notifi- 
cation packet from its identifier, and delivers its contents 
to the group split controlling means 419, In the case 
where the group split controlling means 419 judged, 
based on the rate change conditions transmitted from 
respective requesting clients, that the requesting client 
41 a has conditions with difficulty of coexistence with oth- 
er respective requesting clients in one same multicast 
group, this requesting client 41a performs data recep- 
tion in separate multicast group. The same processing 
is made also by respective requesting clients 41b, — . 



Here, one requesting client set in advance among 
the respective requesting clients 41a, — makes a noti- 
fication to said server 400 to the effect that data recep- 
tion is made also in said separate multicast group. Upon 

5 receipt of this notification, the transmission destination 
group split controlling means 41 8 of said server 400 con- 
trols in a way to transfer the data by other multicast 
group to clients having conditions with difficulty of coex- 
istence in one same multicast group based the notifica- 

io tion, and notifies the rate controlling means 405 of the 
send rate by that other multicast group. The rate con- 
trolling means 405 reads out the stream data from the 
transmission buffer 404 and delivers it to the packet 
transmitting means 402, at ordinary send rate for re- 

is questing clients having conditions enabling coexistence 
in one same multicast group, and at said notified other 
send rate for said other multicast group. 

As described above, by making a plural number of 
clients having conditions enabling coexistence belong 

20 to one same multicast group and distribution stream da- 
ta under the respective multicast addresses for the re- 
spective multicast groups, it becomes possible to im- 
prove the reliability of data transfer to a larger number 
of clients. 

25 Explanation has so far been given only on a case 
where stream data received by a receiving buffer is re- 
produced, but a case is also conceivable in which the 
stream data is stored in a storing means such as hard 
disc, etc., for example. 

30 The system of the present application can be exe- 
cuted by either hardware or software. In the case of ex- 
ecution by software, an embodiment is made by incor- 
porating a program on a storing means H such as hard 
disc, etc. (storing device 503, for example). Moreover, 

35 the program incorporated here can be prepared by 
transplanting a program stored on a portable medium 
such as floppy disc M1 , etc. to the server or the storing 
means H of the client 470 through a floppy disc drive 
FD, as shown in Fig. 1 3. 

40 As it is apparent from the explanation given above, 
according to the present invention, no omission of data 
is produced because no overflowing of stream data 
takes place in the receiving buffer. Moreover, even in 
case of occurrence of loss of data for some reason or 

^5 another, such loss of data can be compensated for 
thanks to the possibility of re-transfer of lost data. 

Furthermore, the present invention can be applied 
even to a multicast system constituted by a plural 
number of clients and servers. 

50 

Claims 



55 



1. A stream data transfer method, comprising the 
steps of transferring stream data from a storing 
means on the server side to client at a prescribed 
send rate through a network, and, on the client side, 
receiving said stream data sent out from the server 



10 



BNSDOCID: <EP 



0868059A2_I_> 



19 



EP O 868 059 A2 



20 



with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that a request for change of 
rate is issued from the client side in correspondence 
to the state of vacant area in said receiving buffer, 
and the send rate on the server side is changed 
based on that rate change request. 

2. A stream data transfer method, comprising the 
steps of transferring stream data from a storing 
means on the server side to client at a prescribed 
send rate through a network, and, on the client side, 
receiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that a request for re-transfer 
is issued from the client side in correspondence to 
the loss of data received by said receiving buffer, 
and the data corresponding to the lost data is sent 
out from the storing means on the server side based 
on that request for re-transfer. 

3. A stream data transfer method, comprising the 
steps of transferring stream data from a storing 
means on the server side to client at a prescribed 
send rate through a network, and, on the client side, 
receiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that a request for change of 
rate is issued from the client side in correspondence 
to the state of vacant area in said receiving buffer, 
and the send rate on the server side is changed 
based on that rate change request, and that 

a request for re-transfer is issued from the cli- 
ent side in correspondence to the loss of data re- 
ceived by said receiving buffer, and the data corre- 
sponding to the lost data is sent out from the storing 
means on the server side based on that request for 
re-transfer. 

4. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 
transfer from client, stream data read out at pre- 
scribed send rate from a storing means based on 
the control by a rate controlling means into packet 
and transferring it to the client through a network, 
and client for receiving the stream data sent out 
from the server with a packet receiving means and 
once storing it in a receiving buffer, 

characterized in that said server is provided 
with a rate change request processing means for 
renewing the send rate set on said rate controlling 
means, based on the request for change of rate is- 
sued from the client side in correspondence to the 
state ofvacant capacity in the receiving buffer of 
said client. 



5. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 
transfer from client, stream data read out at pre- 
scribed send rate from a storing means based on 

5 the control by a rate controlling means into packet 

and transferring it to the client through a network, 
and client for receiving the data sent out from the 
server with a packet receiving means and once stor- 
ing it in a receiving buffer, 

1° characterized in that said server is provided 

with a re-transfer controlling means for performing 
re-transfer of the data corresponding to the lost da- 
ta, based on the request for re-transfer issued from 
the client side in correspondence to the state of loss 

is of data received by the packet receiving means of 
the client. 

6. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 

20 transfer from client, stream data read out at pre- 
scribed send rate from a storing means based on 
the control by a rate controlling means into packet 
and transferring it to the client through a network, 
and client for receiving the data sent out from the 

25 server with a packet receiving means and once stor- 
ing it in a receiving buffer, 

characterized in that said server is provided 
with a rate change request processing means for 
renewing the send rate set on said rate controlling 

30 means, based on the request for change of rate is- 
sued from the client side in correspondence to the 
state of vacant capacity in the receiving buffer of 
said client, and 

a re-transfer controlling means for performing 

35 re-transfer of the data corresponding to the lost da- 
ta, based on the request for re-transfer issued from 
the client side in correspondence to the state of loss 
of data received by the packet receiving means of 
the client. 

40 

7. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 
transfer from client, stream data read out at pre- 
scribed send rate from a storing means based on 

45 the control by a rate controlling means into packet 
and transferring it to the client through a network, 
and client for receiving the data sent out from the 
server with a packet receiving means and once stor- 
ing it in a receiving buffer, 

50 characterized in that said client is provided 

with a rate change requesting means for monitoring 
the vacant capacity of said receiving buffer and 
making a request for change of rate conformable to 
that vacant capacity. 

55 

8. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 
transfer from client, stream data read out at pre- 



11 



8NSDOCID: <EP. 



0868059A2J_> 



21 



EP 0 868 059 A2 



22 



scribed send rate from a storing means based on 
the contrbl by a rate controlling means into packet 
and transferring it to the client through a network, 
and client for receiving the data sent out from the 
server with a packet receiving means and once stor- 
ing it in a receiving buffer, 

characterized in that said client is provided 
with a. re-transfer requesting means for monitoring 
loss of the data received by said packet receiving 
means and requesting re-transfer of the data corre- 
sponding to the lost data. 

9. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 
transfer from client, stream data read out at pre- 
scribed send rate from a storing means based on 
the control by a rate controlling means into packet 
and transferring it to the client through a network, 
and client for receiving the stream data sent out 
from the server with a packet receiving means and 
once storing it in a receiving buffer, 

characterized in that said client is provided 
with a rate change requesting means for monitoring 
the vacant capacity of said receiving buffer and 
making a request for change of rate conformable to 
that vacant capacity, and 

a re-transfer requesting means for monitoring 
loss of the data received by said packet receiving 
means and requesting re-transfer of the data corre- 
sponding to the lost data. 

10. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 
transfer from client, stream data read out at pre- 
scribed send rate from a storing means based on 
the control by a rate controlling means into packet 
and transferring it to the client through a network, 
and client for receiving the data sent out from the 
server with a packet receiving means and once stor- 
ing it in a receiving buffer, 

characterized in that said server is provided 
with a rate change request processing means for 
renewing the send rate set on said rate controlling 
means, based on the request for change of rate is- 
sued from the client side in correspondence to the 
state of vacant capacity in the receiving buffer of 
said client, while 

said client is provided with a rate change re- 
questing means for monitoring the vacant capacity 
of said receiving buffer and making a request for 
change of rate conformable to that vacant capacity. 

11. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 
transfer from client, stream data read out at pre- 
scribed send rate from a storing means based on 
the control by a rate controlling means into packet 
and transferring it to the client through a network, 



and client for receiving the data sent out from the 
server with a packet receiving means and once stor- 
ing it in a receiving buffer, 

characterized in that said server is provided 
with a re-transfer controlling means for performing 
re-transfer of the data corresponding to the lost da- 
ta, based on the request for re-transfer issued from 
the client side in correspondence to the state of loss 
of data received by the packet receiving means of 
the client, while 

said client is provided with a re-transfer re- 
questing means for monitoring loss of the data re- 
ceived by said packet receiving meansjand request- 
ing re-transfer of the data corresponding to the lost 
data. 

12. A stream data transfer system, comprising a server 
for editing, upon receipt of a request for start of 
transfer from client, stream data read out at pre- 
scribed send rate from a storing means based on 
the control by a rate controlling means into packet 
and transferring it to the client through a network, 
and client for receiving the data sent out from the 
server with a packet receiving means and once stor- 
ing it in a receiving buffer, 

characterized in that said server is provided 
with a rate change request processing means for 
renewing the send rate set on said rate controlling 
means, based on the request for change of rate is- 
sued from the client side in correspondence to the 
state of vacant capacity in the receiving buffer of 
said client, and 

a re-transfer controlling means for performing 
re-transfer of the data corresponding to the lost 
data, based on the request for re-transfer is- 
sued from the client side in correspondence to 
the state of loss of data received by the packet 
receiving means of the client, while 
said client is provided with a rate change re- 
questing means for monitoring the vacant ca- 
pacity of said receiving buffer and making a re- 
quest for change of rate conformable to that va- 
cant capacity, and 

a re-transfer requesting means for monitoring 
loss of the data received by said packet receiv- 
ing means and requesting re-transfer of the da- 
ta corresponding to the lost data. 

13. A stream data transfer system as defined in either 
one of Claims 5,6, 11 or 1 2, wherein said rate con- 
trolling means delivers to data forming the subject 
of the transfer to the packet transmitting means by 
attaching information indicating the position on the 
file of that data and, upon receipt of said request for 
re-transfer, sends out said position information of 
the data regarding said omission together with said 
data forming the subject of the transfer. 
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14. A stream data transfer system as defined in either 
one of Claims 5, 6, 11 or 1 2, wherein said re-transfer 
controlling means manages information identifying 
the position on the file of the data and packet 
number relating with each other, and wherein said 5 
rp-rarlsfer request is produced, determines the lost 
packet by the packet number included in the re- 
ransfer request. 

15. A stream data transfer system as defined in either 10 
one of Claims 7, 9, 10 or 12, wherein said rate 
change requesting means delivers, to the packet 
transmitting means, a request for change of rate for 
lowering the send rate in the case where the vacant 
capacity in the receiving buffer decreased below the 
prescribed lower limit and a request for change of 
rate for raising the send rate in the case where the 
vacant capacity in the receiving buffer increased 
above the prescribed upper limit. 

20 

16. A stream data transfer system as defined in either 
one of Claims 7, 8, 10 or 12, wherein the rate 
change requesting means delivers, to the packet 
transmitting means, a request for change of rate for 
changing the send rate to 0 in the case where the 25 
vacant capacity decereased under the prescribed 
under limit in the receiving buffer and a request for 
change of rate for requesting prescribed send rate 

in the case where a vacant capacity increased over 
the prescribed upper limit in the receiving buffer. 30 

17. A stream data transfer system as defined in either 
one of Claims 8, 9, 11 or 12, wherein information 
identifying the position on the file of data is incorpo- 
rated in the data packet, and said re-transfer re- 35 
questing means detects said loss of data based on 
said information identifying the position on the file 

of the lost data, and identifies the re -transferred da- 
ta by including said position information of lost data 
in said request for re-transfer. 40 

18. A stream data transfer system as defined in either 
one of Claims 8, 9, 1 1 or 1 2, wherein said re-transfer 
controlling means detect packet number of lost 
packet and the packet transmitting means send the 45 
re-transfer request packet incorporated the 
number. 

19. A multicast stream data transfer method, compris- 
ing the steps of transferring stream data from a stor- so 
ing means on the server side to a single client or a 
plurality of clients belonging to one same multicast 
group at a prescribed send rate through a network, 
and, on the client side, receiving said stream data 
sent out from the server with a packet receiving ss 
means and once storing it in a receiving buffer, 

characterized in that a request for change of 
rate is issued from the client side in correspondence 



59 A2 24 

to the state of vacant area in said receiving buffer 
of specific client belonging to one same multicast 
group, and the send rate on the server side is 
changed based that rate change request. 

20. A multicast stream data transfer method as defined 
in Claim 19, wherein said specific client issues said 
request for change of rate to said server and all cli- 
ents belonging to said one same multicast, issu- 
ance by other specific client of request for change 
of rate identical to said request for change of rate is 
prohibited for a prescribed time set irij advance. 

21 . A multicast stream data transfer method as defined 
in Claim 19, wherein said server validates, in the 
case where a request for change of rate of one 
same contents was received from a plurality of cli- 
ents within a prescribed time set in advance, one of 
those rate change requests and changes the send 
rate of the server based on that rate change re- 
quest. 

22. A multicast stream data transfer method, compris- 
ing the steps of transferring stream data from a stor- 
ing means on the server side to a single client or a 
plurality of clients belonging to one same multicast 
group at a prescribed send rate through a network, 
and, on the client side, receiving said stream data 
sent out from the server with a packet receiving 
means and once storing it in a receiving buffer, 

characterized in that a request for re-transfer 
is issued from the client side to the server in corre- 
spondence to a loss of the data received by the 
packet receiving means of specific client belonging 
to one same multicast group, and the data corre- 
sponding to the lost data is sent out from the storing 
means of the server based on that request for re- 
transfer. 

23. A multicast stream data transfer method as defined 
in Claim 22, wherein said specific client issues said 
request for re-transfer to said server and all clients 
belonging to said one same multicast, issuance by 
other specific client of request for re-transfer iden- 
tical to said request for re-transfer is prohibited for 
a prescribed time set in advance. 

24. A multicast stream data transfer method as defined 
in Claim 22, wherein said server validates, in the 
case where a request for re-transfer of one same 
contents was received from a plurality of clients 
within a prescribed time set in advance, one of 
those re-transfer requests and send out the data 
corresponding to the lost data from the storing 
means of the server side based on that request for 
re-transfer. 

25. A multicast stream data transfer method as defined 
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in either one of Claims 19 to 21, wherein, before 
transmission of stream data, said server obtains, 
from all clients belonging to one same multicast 
group capable of transmitting said request for 
change of rate, conditions for issuance by the cli- 
ents of a request for change of rate, and transfers 
the data to said client having conditions with diffi- 
culty of coexistence in one same multicast group, 
as other multicast group. 

26. A multicast stream data transfer method as defined 
in either one of Claims 19 to 21, wherein, before 
transmission of stream data, said specific client ob- 
tains, from ail clients belonging to one same multi- 
cast group capable of transmitting said request for 
change of rate, conditions for issuance by the other 
clients of a request for change of rate, and receives 
the data, as other multicast group, in the case where 
this other client has conditions with difficulty of co- 
existence in one same multicast group. 

27. A multicast stream data transfer method as defined 
in either one of Claims 19 to 21, wherein, when 
there is a request for transfer to a new client during 
a transmission of stream data, the data is trans- 
ferred by other multicast group to said new client, 
in the case where the conditions for issuing a re- 
quest for change of rate of that new client are con- 
ditions having difficulty of coexistence in the multi- 
cast group already under transmission. 

28. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 
to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that specific client belonging 
to one same multicast group is provided with a rate 
change requesting means for monitoring the vacant 
capacity of said receiving buffer and issuing a re- 
quest for change of rate conformable to that vacant 
capacity to said server. 

29. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 
to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that said server is provided 
with a rate change request processing, means for 
renewing, based on the rate change request issued 
from the client side in correspondence to the sate 



of vacant capacity in the receiving buffer of said cli- 
ent, the send rate set on said rate controlling 
means. 

5 30. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 
to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- 

10 ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that said server is provided 
with a rate change request processing means for 

is renewing, based on the rate change request issued 
from the client side in correspondence to the sate 
of vacant capacity in the receiving buffer of said cli- 
ent, the send rate set on said rate controlling 
means, and that 

20 said specific client belonging to one same 

multicast group is provided with a rate change re- 
questing means for monitoring the vacant capacity 
of said receiving buffer and issuing a request for 
change of rate conformable to that vacant capacity 

25 to said server. 

31 . A multicast stream data transfer system as defined 
in Claim 28 or 30, wherein said server is provided 
with a transmission destination group split control- 

30 |jng means for controlling, depending on the condi- 
tions of issuance of rate change request by a client 
provided with said rate change requesting means, 
in a way to transfer the data by other multicast group 
to said client having conditions with difficulty of co- 

35 existence in one same multicast group. 

32. A multicast stream data transfer system as defined 
in Claim 28 or 30, wherein said specific client is pro- 
vided with a group split controlling means for receiv- 

40 jng the data, based on the conditions of issuance of 
rate change request by other specific client, by oth- 
er multicast group in the case where this specific 
client has conditions with difficulty of coexistence in 
one same multicast group. 

45 

33. A multicast stream data transfer system as defined 
in Claim 32, wherein said group split controlling 
means issues, to said server, a request for transfer 
to other multicast group. 

so 

34. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 
to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 

55 rate through a network, and, on the. client side, re- 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, 
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characterized in that said specific client be- 
longing to one same multicast group is provided 
with a re-transfer requesting means for monitoring 
loss pf the data received by said packet receiving 
means and requesting re-transfer of the data corre- s 
spending to the lost data. 

35. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 

to a single client or a plurality of clients belonging 10 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, is 

characterized in that said server is provided 
with a re-transfer controlling means for performing 
re-transfer of the data corresponding to the lost da- 
ta, based on the request for re-transfer issued from 
the client side in correspondence to the state of loss 20 
of data received by the packet receiving means of 
the client. 

36. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 2 s 
to a single client or a plurality of clients belonging 

to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 30 
in a receiving buffer, 

characterized in that said server is provided 
with a re-transfer controlling means for performing 
re-transfer of the data corresponding to the lost da- 
ta, based on the request for re-transler issued from 35 
the client side in correspondence to the state of loss 
of data received by the packet receiving means of 
the client, while 

said specific client belonging to one same 
multicast group is provided with a re-transfer re- *o 
questing means for monitoring loss of the data re- 
ceived by said packet receiving means and request- 
ing re-transfer of the data corresponding to the lost 
data. 

45 

37. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 
to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- so 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 

in a receiving buffer, 

characterized in that said server is provided 
with a rate change request processing means for ss 
renewing the send rate set on said rate controlling 
means, based on the request for change of rate is- 
sued from the client side in correspondence to the 



28 

state of vacant capacity in the receiving buffer of 
said client, and 

a re-transfer controlling means for performing 
re-transfer of the data corresponding to the lost da- 
ta, based on the request for re-transfer issued from 
the client side in correspondence to the state of loss 
of data received by the packet receiving means of 
the client. 

38. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 
to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that said specific client be- 
longing to one same multicast group is provided 
with a rate change request processing means for 
renewing, based on the rate change request issued 
from the client side in correspondence to the sate 
of vacant capacity in the receiving buffer of said cli- 
ent, the send rate set on said rate controlling 
means, and 

a re-transfer requesting means for monitoring 
loss of the data received by said packet receiving 
means and requesting re-transfer of the data corre- 
sponding to the lost data. 

39. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 
to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that said server is provided 
with a rate change request processing means for 
renewing the send rate set on said rate controlling 
means, based on the request for change of rate is- 
sued from the client side in correspondence to the 
state of vacant capacity in the receiving buffer of 
said client, and 

a re-transfer controlling means for performing 
re-transfer of the data corresponding to the lost 
data, based on the request for re-transfer is- 
sued from the client side in correspondence to 
the state of loss of data received by the packet 
receiving means of the client, while 
said specific client belonging to one same mul- 
ticast group is provided with a rate change re- 
quest processing means for renewing, based 
on the rate change request issued fronrvthe cli- 
ent side in correspondence to the sate of vacant 
capacity in the receiving buffer of said client, 
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the send rate set on said rate controlling 
means, and 

a re-transfer requesting means for monitoring 
loss of the data received by said packet receiv- 
ing means and requesting re-transfer of the da- s 
ta corresponding to the lost data. 



30 

scribed time set in advance, one of those re-transfer 
requests. 

44. A recording medium in which is stored the respec- 
tive procedures indicated in said Claims 1 to 43. 



40. A multicast stream data transfer system as defined 
in either one of Claims 28, 30, 38 or 39, wherein 
said rate change requesting means transfers said io 
rate change request to said server and all clients 
belonging to said one same multicast group, while 
said specific client is provided with a rate change 
request inhibiting means for inhibiting issuance of 
rate change request of contents identical to those is 
of the rate change request issued by other specific 
client, for a prescribed time set in advance. 

41. A multicast stream data transfer system as defined 

in either one of Claims 34, 36, 38 or 39, wherein 20 
said re-transfer requesting means transfers said re- 
transfer request to said server and all clients be- 
longing to said one same multicast group, while said 
specific client is provided with a re-transfer inhibit- 
ing means for inhibiting issuance of re-transfer re- 25 
quest of contents identical to those of the re-transfer 
request issued by other specific client, for a pre- 
scribed time set in advance. 



42. A multicast stream data transfer system transferring 30 
stream data from a storing means on the server side 

to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- 
ceiving said stream data sent out from the server 35 
with a packet receiving means and once storing it 
in a receiving buffer, 

characterized in that said server is provided 
with a one same rate change request processing 
means for validating, in the case where said server 40 
received request for change of rate of one same 
contents from a plural number of clients within a pre- 
scribed time set in advance, one of those rate 
change requests. 

45 

43. A multicast stream data transfer system transferring 
stream data from a storing means on the server side 
to a single client or a plurality of clients belonging 
to one same multicast group at a prescribed send 
rate through a network, and, on the client side, re- so 
ceiving said stream data sent out from the server 
with a packet receiving means and once storing it 

in a receiving, buffer, 

characterized in that said server is provided 
with a one same re-transfer request processing 55 
. means for validating, in the case where said server 
received request for re-transfer of one same con- 
tents from a plural number of clients within a pre- 
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[Fig. 6] 
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